home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9805 / 000205_owner-linux-arm…r.rutgers.edu _Thu May 28 14:26:09 1998.msg < prev    next >
Internet Message Format  |  1998-06-02  |  4KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from virtual.bbc.co.uk (virtual.bbc.co.uk [132.185.132.199])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id OAA24942
  4.     for <willy@odie.barnet.ac.uk>; Thu, 28 May 1998 14:26:08 +0100
  5. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
  6.     by virtual.bbc.co.uk (8.8.5/8.8.5) with ESMTP id OAA13378
  7.     for <willy@bofh.ai>; Thu, 28 May 1998 14:26:52 +0100 (BST)
  8. Received: from vger.rutgers.edu ([128.6.190.2]:63857 "EHLO vger.rutgers.edu" ident: "root") by nic.funet.fi with ESMTP id <2392-669>; Thu, 28 May 1998 16:26:40 +0300
  9. Received: by vger.rutgers.edu id <971043-21547>; Thu, 28 May 1998 08:30:36 -0400
  10. Received: from relay1.UU.NET ([192.48.96.5]:1564 "EHLO relay1.UU.NET" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <971024-21547>; Thu, 28 May 1998 08:30:14 -0400
  11. Received: from xedia.com by relay1.UU.NET with SMTP 
  12.     (peer crosschecked as: madway.xedia.com [198.202.232.199])
  13.     id QQerib23236; Thu, 28 May 1998 09:25:19 -0400 (EDT)
  14. Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1)
  15.     id AA02880; Thu, 28 May 98 09:26:02 EDT
  16. Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4)
  17.     id JAA21800; Thu, 28 May 1998 09:25:17 -0400
  18. Date:     Thu, 28 May 1998 09:25:17 -0400
  19. Message-Id: <199805281325.JAA21800@tonga.xedia.com>
  20. From: Paul Koning <pkoning@xedia.com>
  21. Mime-Version: 1.0
  22. Content-Type: text/plain; charset=us-ascii
  23. Content-Transfer-Encoding: 7bit
  24. To: shanske@ix.urz.uni-heidelberg.de
  25. Cc: linux-arm@vger.rutgers.edu
  26. Subject: Re: mtools 3.6 
  27. References: <Pine.A41.3.96.980528150029.26868A-100000@aixterm7.urz.uni-heidelberg.de>
  28. X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs  Lucid
  29. X-Orcpt: rfc822;linux-arm@vger.rutgers.edu
  30. Sender: owner-linux-arm@vger.rutgers.edu
  31. Precedence: bulk
  32. X-Loop: majordomo@vger.rutgers.edu
  33. Status: RO
  34.  
  35. >>>>> "Stefan" == Stefan Hanske <shanske@ix.urz.uni-heidelberg.de> writes:
  36.  
  37.  
  38.  Stefan> The problem with mtools I had was that gcc didn't layout the
  39.  Stefan> structure vfat_subentry as it's ment to be and since this
  40.  Stefan> struct is written to disc 'as is' (as a block of memory
  41.  Stefan> instead of fields) this is a problem that corrupts
  42.  Stefan> discs. Have a look at the following code:
  43.  
  44. struct unicode_char {
  45.             char lchar;
  46.             char uchar;
  47. };
  48.  
  49. struct vfat_subentry {
  50.             ...
  51.             struct unicode_char text1[x] PACKED;
  52.             ...
  53. };
  54.  
  55.  Stefan> This should advise gcc to create x copies of unicode_char in
  56.  Stefan> vfat_subentry, allocating 2*x bytes of memory. I don't know
  57.  Stefan> why but gcc makes it use 4 bytes per copy instead.
  58.  
  59.  Stefan> Thats what I called the PACKED bug. Any suggestions?? Is this
  60.  Stefan> repeatable on other machines???
  61.  
  62. I once made the assumption that the standard alignment and sizing of
  63. data items (each primitive of n bytes is aligned/sized to n bytes) is
  64. the exact standard alignment/size rule.  C/C++ language experts
  65. pointed out that this is not true; the standard says that it is the
  66. MINIMUM alignment and implementations may force larger alignment.
  67.  
  68. So the minimum size of struct unicode_char is 2 and the minimum
  69. alignment is 1, but implementations are allowed to increase that.
  70.  
  71. Most don't, but ARM does.  This has caused problems in lots of places
  72. that make the same assumption I did...
  73.  
  74. You might try one of the following:
  75.  
  76. struct unicode_char {
  77.             char lchar;
  78.             char uchar;
  79. } PACKED;
  80.  
  81. or
  82.  
  83. struct unicode_char {
  84.             char lchar PACKED;
  85.             char uchar PACKED;
  86. };
  87.  
  88. So what this means, if I understood everything right, is that the bug
  89. is in mtools (for making a language assumption not supported by the
  90. standard) rather than in gcc.
  91.  
  92.     paul
  93. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu